\subsection{Critical reflection}
\label{sec:criticalreflection}
\subsubsection{Advantages and disadvantages of our system}


\subsubsection{Remaining problems}

\paragraph{Package starvation}
We try to prevent package starvation through a gradual increase of our feasibility ant range. However, since in our current a PickUpPointAgent can not discern between being "unscoutable" to current truck positions or just not being part of an optimal path, it increases its range in both situations. To prevent scalability problems, we therefor included a maximum feasibility ant range. If at the end of the simulation no truck is within this maximum range, the package will starve.

The possibility of package starvation prevents us from correctly comparing the performance of our solution as the number of pick up and delivery sequences increases in a large scale experiment where average values become statistically relevant.

A possible solution to this would be notifying a pick up point when it is scouted by an ant, so a pick up point would only increase its initial feasibility pheromones (range) when left unscouted for a while. To prevent scalability problems this could be done in combination with a longer refresh interval of the feasibility data. Since an increase in initial pheromones also increments the time it takes for all the data to evaporate, this would not lead to absence of feasibility data.

\paragraph{Blind commitment}
Though our design allows for reexploration even when a TruckAgent already has an intention, we did not activate this option in our final system. We did this because we didn't have the time to correctly finetune the relevant parameters. This means of course that our solution doesn't perform as well as it could in an environment where packages get added dynamically. To prevent this from skewing the results of our experiments (as it could, for example, lead to less PnD sequences providing better solutions in borderline situations), we always initialized all packages at the start of the experiment.

\paragraph{Worse solutions when considering multiple sequences}
In some package deployment possibilities, considering multiple sequences of pick up and delivery might lead to worse solutions. This is entirely environment dependant and can not be solved to our knowing.

\paragraph{A crossroad can not be used multiple times as package point}
Due to the way in which we deploy package points and their agents in our design, it's impossible for us to reuse a specific crossroad as a pick up or drop off point for a different package than was initially deployed on this crossroad. This is pretty easy to fix, but would result in some major design changes that would unfortunately propagate themselves pretty far in our code.

\paragraph{A* failure}
There's a few bugs in the Leuven map file that result in failure of the A Star router. Our current design does not handle the NullPointerException that is thrown as a result. To fix this we would have to edit the map file or reroute from the closest neighbouring crossroad.